アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！)

take3000

2016.03.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。

アジャイル・クラウド・DevOps は実際のところどんなものなのか？　上手くいく／上手くいかない取り組みの違いはどこなのか？　そもそもそれは本当にやるべきか？　組織とエンジニアの関係、評価はどのようにすれば良いのか？　といった幅広いテーマについて語っていただきました。

このインタビュー記事は、

アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方
手を付けたけど、なんだか上手くいっていないことにお悩みの方
もしくは自分たちのやり方が正しいのか不安を感じている方
現場のエンジニアから聞く機会が多いので要点を掴んでおきたい経営者の方

にとって有効なヒントになると思います。

14,000文字におよぶ長文インタビューですが、最後まで読んでいただけると嬉しいです。インタビューは城内と嵩原が担当しました。

Ryuzee、最初に自分を語る

城内: あらためて、吉羽さんの経歴を教えていただけますでしょうか。
吉羽さん: 1997年に新卒で入った最初の会社は大手SIer でしたがコードをひたすら書きたくて2年弱で辞めました。それからベンチャー企業で3年半ほど仕事をして、その後、もうちょっと大規模なのをやろうかなと思ってNRI(株式会社野村総合研究所)に転職しました。NRI 時代は、証券系や金融機関などのお客様に Web 系のシステムをたくさん作っていました。この時の体験が、その後のキャリアを決める重要なポイントになっています。

「ソフトウェアは作り方がおかしいんじゃないの？」

吉羽さん

当時はウォーターフォール型のプロジェクトをやっていましたが、ウォーターフォールはWeb開発と相性が良くなくて、実物を見てみないとわからない、動かしてみないとわからないっていうことが多々ありました。最初に見積もりをがんばってやって、それから動くものを作る。でも結局、受入テスト期間中に「これなんか違うなあ…」っていうのが山のようにでてきて…。デスマーチとまではいかないけれど、やり方が上手くないなあっていうのがありました。

その当時、お客様の役員の方から「ちょっとソフトウェアの作り方おかしいんじゃないの？工場とかリアルなものつくりの現場を見たほうがいいよと。」とアドバイス頂きました。

私自身も、「やり方がマッチしていないのでは…」と漠然と感じていました。それで、お客様の紹介でノート PC(Let’s Note や FMV)の製造工場を見学しに行ったのです。そこではすごい”カイゼン”が行われていました。例えば、ノート PC は揺らすと壊れることがあるのですが「震度試験のために肩叩き機をラックにつけて揺らしてみよう」とか、品質を上げるためにプロセスをどんどん変えていく取り組みが実践されていました。他にもカンバンやアンドンなどもやっているのを見て衝撃を受けました。

これらの知見をソフトウェア開発の現場に持ち込んで、アジャイル開発をやるようになりました。上司からは「好きにやっていい。でも、今のやり方はマズイから変えなければならない」というやり取りしていましたね。これがキャリア転換の契機だったと思っています。それから、NRI ではマネジメントもサーバ構築もコーディングもなんでもやっていました。

AWS の中の人になる

吉羽さん

2009年にNRIの役員がスピンアウトして作った会社で、AWS を4年ほど使っていました。

その後、2012年10月の札幌のイベントで玉川さんから誘われたのがきっかけで、翌年4月にアマゾンデータサービスジャパン株式会社(現、アマゾンウェブサービスジャパン株式会社)(以下、AWSJ)に入りました。玉川さんとは彼が IBM に在籍していた時代からの付き合いになります。

AWSJ では AWS プロフェッショナルサービスチームの立ち上げに携わりました。米国では1年先に立ち上がっていたので、プロフェッショナルサービスを日本でも展開させるという形でした。日本通運様などエンタープライズユーザーへのコンサルティング業務の傍らでサービスのメニュー作りも並行して行い、チームをスケールさせていきました。

AWSJ を辞めて、アジャイル・クラウド・DevOps を仕事にする

吉羽さん

AWS プロフェッショナルサービスチームとして活動する過程で、チームのマネージャーになりました。トータルで1年程マネージャーとして仕事に携わりましたが、マネージャーとしての自分の競争力はあまりないかなぁと。マネージャーができないわけではないと思うけど、エンジニアと比べると自分としてはキツイと感じ、再度プレイヤーに戻ろうと思うに至りました。AWSJ の中でプレイヤーに戻るという選択もありましたが、クラウドベンダーはインフラを提供するという立場上、アプリケーション開発に深く踏み込むことには限界があると感じていました。インフラにアジリティができてもモノを作るところにアジリティがなければ意味があまりなくて、インフラとアプリケーションの両側をしっかり見られないと堂々とコンサルしにくいかなと。

アジャイル、クラウド、DevOps の領域を一通り押さえているし、ベンダーに縛られない立場で、どうやったら上手くいくのかっていうのを、とりあえず自分でやろうかな、っていう感じですかね。

城内

元々、アジャイルがあって開発手法が新しくなってきて、並行してクラウドみたいなすぐ使えるインフラが登場してきたけど、それらは別々の線で走ってきていて上手く交わってない。そこに問題意識を感じて、本来あるべき全体を俯瞰して最適化していくために、ベンダーに縛られることのないポジションで仕事をするためにフリーランスになったというわけですね。

組織の利害から離れて”To-Be”を語る必要性

吉羽さん

そうですね。ベンダーの立場になるとベンダーのものを売らなきゃいけない。お客さん側の立場で好き勝手なことを言っても「出来ない」と言われてしまえばそれまで。第三者というのはお客さんとしては便利で、お金は払うけど失敗したらその人のせいにしやすい(笑)。組織の中でやると、どうしても現実の制約を自分が認識した上でやらなきゃいけなくなる。外部だと、その辺を無視してあるべき論を正々堂々と語っても大丈夫。”As-Is”と”To-Be”の”ちゃんとしたTo-Be”を語れるわけです。

あとは、一度はサラリーマンじゃないっていうのを、やってみたいじゃないですか。完全自己責任の世界で。勉強会やイベントで「スキルを身につけなきゃ生きていけないよ」と発言しつつも、自分自身は会社に属して会社から守られるっていうのは説得力がない。なので、試してみようと思いました。

アジャイル・クラウド・ DevOps はどうやって繋がるの？

城内

Ryuzee.com を拝見して、支援内容がアジャイルコーチング、DevOps、クラウドとありました。それぞれご経験があるということですが、各キーワードはどのように繋がるのでしょうか？

吉羽さん

難しい質問なんですけど、DevOps でもクラウドでもアジャイルでも何でも良いですが、エンジニア側から見える絵姿と、非エンジニアである経営者から見える絵姿はまったく違っています。エンジニア側から見る DevOps っていうと、すぐ DevOps ツールとか、プロビジョニングを自動化するとか、イケてる技術感みたいのがでてきます。それ自体が悪いって言っているわけではありませんが、事の本質はビジネスの変化の速度がすごく早い環境になっていて、トラディショナルな会社であろうが、スタートアップであろうが、だいたいが Web とかシステムとかを使ってお金を稼ぐモデルになってきている中で、いかにシステムがボトルネックにならないようにするのが一番重要なポイントなんですね。経営者にとっては、中身の方法論はどうでもよくて、ビジネスのアイディアを出して、マーケットに投入できて、実際にそれがお金を回収できるのかっていうのが、彼らの関心事です。なので、そのサイクルを早く回さないといけないわけです。上手くいかないものは早めに諦めなければいけないし、上手くいところにはどんどんリソースを投下してどんどん儲けるっていう仕組みにならなければならない。これがビジネス的な要求です。

としたときに、予算主義で年初に「今年はこういう機能を作るんだ」って計画立てて、翌年3月末くらいに「全部できました。デプロイしますよ」っていう話がいかに機能しないかっていう話になる。もっともっとフィードバックサイクルを早くまわさないといけないです。スタートアップだったら、そもそも最初のアイディアが合ってないかもしれないんで、ピボットしなければいけないですよねっていう話すらある。システムの作り方を考え直さなければいけない時もあって、そこではじめてアジャイルみたいな話がでてくる。

これにクラウドがどう絡むかっていうと、アジャイルのやり方でフィードバックサイクルをガンガン回すとして、インフラがボトルネックになるのを避けなければならない。今までだったらストレージの調達に3ヶ月かかりますとか、実際に作ってみたら性能が遅くて全然ダメだったので追加で調達するのに何ヶ月待ってくださいとかもマズイし、サービスが急成長する過程でどんどんサーバを足たさなきゃいけないんだけど、それ本当に足すの？みたいな話とか、そもそも Yahoo に載った瞬間に跳ねるのにそんなすぐ調達できませんよ、とかね。そういう話があって、インフラがボトルネックになってはいけない、これを避けるのに多大な先行投資とかはなかなか承認できないよねってなって意思決定が遅れる。そういう問題をなくすためにクラウドがある。アジャイルにやろうとして速度を上げようとしたら、すべからくインフラの調達のリードタイムを縮めないといけない、そこに柔軟性がないといけない、そこにクラウドが役立つ。

DevOps の話は、Dev と Ops の対立っていう軸で語られることが多いけど、それは本質ではない。対立していない組織だって山のようにあるわけですよ。問題はフィードバックサイクルをガンガン回そうとしたときに、要求を突っ込んでから実際にお客さんに価値を届けられるかまでのリードタイムを縮めるってことと、いかにパイプラインを太くするか、スループットをでかくするかが DevOps の本質です。

Dev と Ops が対立しがちだからこういう名前になっているかもしれないですけど、そもそもは組織的に実際の要求から価値の流れを良くしようっていうのが DevOps です。バズワードぽいし、ベンダーさんが「我社の DevOps ツールが…」みたいになりやすいから、みんな誤解しますけど、本質はそこじゃない。どっちかっていうと組織の話です。規模が大きい会社のサイロ化した組織で、コミュニケーションのオーバーヘッドが大きく、そこに利害の相反が存在していて、作るプロダクトの価値より組織の論理が優先されがちっていう問題を解決するのが DevOpsって考えるのがわかりやすい。そういう意味ではアジャイルもそうでしたけどね。

城内

ノートPC工場見学の話のように、ビジネスの要求があって課題を解決しようとしたらこういうのが最適だろうっていうのがでてきて、それに名前を付けたらアジャイルだったり、クラウドだったり、DevOps って呼んでみたりしたけれども、本質的に言えばビジネスのスピードがどんどん早くなってきていることにどう対応していくかってところに行き着くと。

吉羽さん

そういうことです。

アジャイル・クラウド・DevOps を失敗させる勘違いとは

城内: そこを見失ってしまうと上手くいかないのでしょうか？
吉羽さん: 上手くいかないとまでは言わないけど、ツールを使ったり部門の中のプロセス変えたりっていうのは、部分最適化としては効果あるだろうし、それは否定しません。ただ、全体の流れを見たときに、要求がきて開発してデプロイしてお客さんに届いて更に改善してっていうのが、部分最適化とどれくらいリンクするかはわからない。部分最適が全体最適になるわけではない。極論すると、開発チームをこれ以上改善しても全体のリードタイムは縮まないしスループットも上がらないですっていう話はいっぱいある。ボトルネックはどこなのっていう話をしないと、本当の効果は得られないと思います。
城内: 取り組む上でのポイントはいかがでしょうか？
吉羽さん: 難しい質問ですけど、プロセスを導入することが目的になっているとだいたい上手くいかないですね。クラウドもそうだし、アジャイルもそうだけど、流行ると日経コンピュータなどのメディアに載り、偉い人が関心を持って「うちはやってないの？」っていう感じになる。そしてトップダウンで現場に指示が落ちてきて、理由はわからないけどクラウドを使わないといけない、アジャイルでやらないといけない、なんてことになりがちです。ビジネスのコンテキストに関係なく新しいことをやると、上手くいかないことが多い。チームのメンバーやプロジェクトのステークホルダーからの「なんで、ここでそれなんだっけ？」という質問に明確に説明できないような技術選定とか、プロセス選定だと辛いですね。

“Don't DO Agile, BE Agile.”

城内: あくまでアジャイルは手法の名前であって、アジャイルが目的ではないことを理解しておくことがポイントでしょうか？
吉羽さん: そうです。アジャイルには”Don't DO Agile, BE Agile.”という話があって、アジャイルであること(俊敏性が高いこと)が重要であって、アジャイルをすることは大事ではない。もちろん、やったことがない人はスクラムやXP(eXtreme Programming)といったやり方に取り組むことでいろんな知見が集まるので、まずはそういうフレームワーク化されているものからやれば良いんだけど、自分たちが成熟していったらやり方を変えていっても良いでしょう。武道でいうと守破離です。最初は型に従ってやります、だんだん変えていって、最後は自分たちのやり方ができる。これをスクラムと呼ぼうが XP と呼ぼうが、自分たちのやり方はアジャイルですっていうのが理想の姿ですよね。”

守破離

城内: いまあるフレームワークを導入して、自分たちに合わせて変えていくと。
吉羽さん: そうそう。ただし、誤解がないように言っておかなければいけないのは、最初は型にはめる方が望ましい。「会社のやり方に合わないので全部変えちゃう」とか「できないから変えちゃう」というのでは、手法を導入する意味がわからなくなってしまうからです。乗り越えてから、徐々に自分たちのやり方に変えていくのが良いと思います。
城内: 導入するときは、まずは選択したものをやってみると。
吉羽さん: そうですね。それをどんどん改善していく。もちろん機能しないところもいっぱいでてくるけど、それはふりかえりを2週間とかに1回やって、今の問題とそれをどうやって直すのかっていう”検査”と”適応”をひたすら繰り返す。そこでだんだん良くしていくという感じですかね。これはクラウドもDevOpsも関係なく、そういうやり方をしないと上手くいくようにならない。

アジャイル・クラウド・DevOps と組織の問題

城内: そういう点では、弊社(クラスメソッド)や立ち上げたばかりの小さい会社の規模であれば比較的やりやすいと思うんですが、エンタープライズのユーザーではいかがでしょうか？　開発部門がそう決めたとしてもインフラ部門は見解が違っていたり、開発の中でも基幹系とWeb系で分かれていたりすると浸透させるのが難しいケースもあると思います。どういったアプローチにしていくと、最適化が促せるのでしょうか？
吉羽さん: これも共通することですが、すべてビジネスオリエンテッドであるべきです。ビジネスの課題を解決するためにやり方を変える。誰がジャッジできるかという点では経営者ですね。現場の開発者がどれだけアジャイルといっても部分最適化するだけです。ただし、経営者がリーダーシップを持って取り組むだけでは現場は「えー！」ってなるでしょうし、これはこれで上手くいかない。トップダウンとボトムアップ両方の熱量が大事です。ボトムアップだけだと自分たちの範囲を越えて行くことができない。バグが減ったりするかもしれないけれど、ビジネスの流れとしてのリードタイムはあまり変わらないと思います。ある程度、経営層の力が必要です。特にエンタープライズだとそうですね。海外は経営者の関与度が高い。全社的に自分たちを変えていかないとまずいっていうのを、リーダーシップをもって活動しています。小規模な組織に新しい物をいれるのと、大規模の組織で同じことをするのではだいぶ違うでしょう。
城内: 組織には、経営者・部門トップ・現場の担当者といった役職の人や、事業部・開発部門・人事総務など様々な役割をもった部門・部署が存在します。吉羽さんが想定しているクライアントはどういった方たちでしょうか？
吉羽さん: 開発のやりかた、インフラ戦略、採用戦略なども含め、特定の業種や企業の規模などで限定はしていません。ただし、開発チームの支援だけをやっても効果はあまり出ないので、あえてスコープは広くしています。事業部門からでも声がかかったらご支援します。

そのクラウド、本当に必要ですか？

城内

現場レベルから声がかかったとしても考え方は一緒で、ビジネスを考えて導入すると？

吉羽さん

そうですね。例えばツールやテクニックだけ取り組んでもあまり変わりません。思想の部分が大事です。なんにせよ、支援を依頼されたら思想のところをやります。

御社(クラスメソッド)もユーザーから「コスト削減のためにAWSを使いたい」という問い合わせをよく受けるでしょ？　そういった依頼に対して「クラウドの本質的な価値はそこではなくて、アジリティが上がるところですよ」と言いたいところですが、クラウドベンダーから言うのは難しい。コスト削減ってキャッチーですし、お客さんも業績が思うように上がっていなければコストを削りたくもなりますし。そこはクラウドベンダーと異なる立場として強く言っていきたいです。

実際は人件費の方が圧倒的に高い。人件費は固定費として不可侵領域になりがちです。箱モノとか設備のコストを削りたくなる一方で、本質的にはビジネスの売上に貢献していない人を減らして、儲けに貢献できるところに人を増やすかっていう話じゃないですか。できれば、そういうことを伝えてストレートに受け止めてくれるお客さんと仕事がしたいですね。「とは言っても、僕達の力じゃどうにもならないんですよ」って言われたら辛いじゃないですか(苦笑)。

城内

ありがちといえばありがちですね。そうすると、手法から入ることもあるかもしれないけど、やはり組織的に変わらなければというところも出てくると思います。その辺りのコンサルも含めてフリーランスになった今なら、第三者的にいろいろ支援できるということでしょうか？

吉羽さん

アジャイルのやり方に変えていくと、採用や人事評価の話も出てきます。その辺の話もしないといけない。その辺も含めて、開発、インフラ、組織、ビジネスの話を含め全体でやっていきたいです。

ウォーターフォールからアジャイルへのつまずくポイント

城内

アジャイルの取り組みでは、組織変更も場合によっては必要になってくると思います。導入にあたり、変更するポイントや導入のコツのようなものはありますか？　また、ウォーターフォールからアジャイルへの移行ではどこにつまずくのでしょうか？

吉羽さん

何点かあります。一つは予算。計画を立てて予算承認をもらってから始めるわけですが、アジャイルは要求が変わるという前提と、ウォーターフォールの後からの変更コストが高いという前提のギャップですね。決まるから見積もれるわけで。アジャイルの場合は、本当に全部作れるかはわからないけど優先順位をつけて、上から順に作っていくことになります。やみくもにやるわけではなく、ある程度スコープを明らかにしておくのはウォーターフォールもアジャイルも同じです。考え方の違い、価値観の違い、変化することが当たり前というのを受け入れられるか。開発チームだけなら上手くいくかもしれないけど、それだけではなく外部の人達も変わる必要がある。アジャイルは、作って、それをステークホルダーに見てもらうというビジネス側の継続的な関与が必要です。そして、エンジニアリング。スプリントを切ってできたものっていうのは、実際にやるかどうかに関わらずリリース可能である必要があります。Web層を書く人、モデルやコントローラを書く人、DBを管理する人というように役割が別れてしまうと一気通貫は難しいでしょう。完全にフルスタックでやれとは言いませんが、ケーキのカットの話にあるように、エンドツーエンドでモノを作成することが必要です。

あと、テスト。スクラムでは、スプリント単位(たとえば2週間)でリリース可能なものを作ろうとします。その場合、品質基準を満たさなければなりません。毎回手動で回帰テストを回せないので、自動テストをやるかクオリティの作りこみをプロセスに入れるか…。技術的に習得しないといけないことも出てきますし、マインドセットも変わります。

これらがアジャイルのハマりやすいところです。そういう意味では、全部ハマりやすのかもしれませんが(笑)。

フルスタックエンジニアは必要か？

城内

従来は役割で分けられることが多い中で、メンバーにフルスタックに近いスキルを身につけてもらうのか、それともアジャイルでやるということを社外に宣言しそういう人を採用するのと、どちらの方が良いでしょうか？

吉羽さん

楽なのは、何でもできる人がいっぱいいることですけどね(笑)。現実解として、上から下まで一気通貫でできる人はそんなにいないでしょう。海外みたいに、今いる人を解雇して新しい人を入れるというのも難しい。

よくやるのは、プロジェクトで必要なスキルと今いるメンバーのスキルのギャップを見える化するために、スキルマップを作ることです。また、特定の誰かしか出来ないことは多重化してマップを埋めていく。例えば Go 言語での開発にチャレンジするとして、スキルマップによって誰も Go ができないということが分かると、そもそもそのプロジェクトできるの？という話にもなりますよね(笑)。そういうリスクを見える化して、技術選定を変えるっていうケースの方が多いでしょうね。

チームとしてフルスタックという体制が必要ですね。

アジャイルで上手くいくとき、ウォーターフォールで上手くいくとき

城内

ちなみに、アジャイルを採用・導入し、時間が経った組織もあると思います。新たな問題や課題などが出てくることもあるのでしょうか？

吉羽さん

アジャイルのやり方は、僕個人としては最適な手法だと思っています。ただしそこには、予測がしづらく変化の量が多い領域においては、という枕詞がつきます。ビジネス要求が変わらないことがわかっているのであれば、恐らくウォーターフォールの方が速いでしょう。

城内

アジャイルが最適かどうかは考えたほうがいいと？

吉羽さん

そうです。ウォーターフォールの方が上手くいくプロジェクトだってあります。なんでもかんでもアジャイルっていうのは違う。プロジェクトの特性を見極めなくてはいけません。

クラウドについても「これ本当にクラウドに載せるの？」という話もあるでしょうし(笑)。

城内

流行っているから上手くいくとは限らず、ウォーターフォールで順に問題を潰すことで上手くいくケースもあると。

吉羽さん

例えば、大規模な金融系システム。そもそも、日本の大規模金融系は複数の開発会社が入り混じることになり、チームビルディングってなんですかっていう状態になりがちです。モチベーションもバラバラで、新しいことを学びたいと思っていない人にアジャイルを強要するというのは無理があります。大規模アジャイル、分散アジャイルは、外部発注して多重請負の日本では大変だろうし難しいと思います。それは”Being Agile”ではなく、”Doing Agile”になってしまう。

プロジェクトによって、どのやり方でやったらいいかを最初に決めるべきですね。流行っているから、という理由で決めないこと。インフラも一緒です。

お客さんへストレートにダメ出しできるか？

城内

吉羽さんにご依頼があった場合、その適性があるかどうかから入るのですか？

吉羽さん

そうです。「やらなくても良くないですか？」って言うこともあります。

「なんでもクラウドに移しましょう」というよりは、場合によっては外部の SaaS にシステムごと乗り換える方が、運用もしなくてもいいし、人件費も含めてコストも安く効率も良くなるかもしれない。旧来の開発会社の中だとできないけど、今ならできます。ユーザーが満足しないのにお金をもらうのはしんどいです。今は、正しい行いを続けることができ、それが信頼を生むと思います。案件をやったほうが儲かるけど、短期的な利益よりも長期的な利益を考えたほうが良いし、お客さん中心で考えたほうがビジネスのサイクルは回りやすい。ダメなものはダメってストレートに言った方が親切です。

城内

弊社でも AWS やビッグデータ分析の引き合いで声がかかるけど、そもそもそのデータ分析は必要なのか？投資するべきなのか？というときもある。本当にAWSにもっていくべきなのか？弊社の横田もよく言うのですが、ユーザーとの信頼関係の醸成が重要なので、本当のことをちゃんと伝えるようにしています。そうすれば、その案件はとれなくなるかもしれませんが、新たな課題が出てきた時に声をかけてもらえることもあるかと思っています。

アジャイル都市伝説、プロダクトバックログはどこまで作るのが正解？

城内

計画駆動開発では業務設計や要件定義からどんな機能が必要かを洗い出しますが、アジャイル開発で最初にプロダクトバックログを作るまでにはどういった準備が必要でしょうか？

吉羽さん

同じです。要件定義はアジャイルにおける最大の誤解で、要件も決めないでいきなりコードを書き出すなんてことはありえません。どこまでやるかの度合いに差があるだけです。

システムのアーキテクチャは後から変えるのが大変ですから、アジャイルだからといって後から変えます、とは言えません。度合いの違いですね。ウォーターフォールは、全てを明らかにして作業が逆流しないように。アジャイルは、本当に重要な事が解っているなら、残りはギリギリまで意思決定を遅らせるっていうのが基本的な考え方。ジャストインタイムで要求を発見してっていう言い方をするときもあります。その方が速い時もあるでしょうしね。もちろん、業務設計も必要です。

城内

そこはアジャイル、ウォーターフォールは関係なく、どういう目的で何を作るのかという青写真はあって、それをベースにどこから手を付けるのか優先度付けをしていくと。

吉羽さん

そうです。網羅性か優先順位か、というところはだいぶ違います。誰がどう見ても1〜20番目くらいまでは大事だろうとわかる。そこから頑張って並べて、498番目と499番と500番のどれが優先順位が高いかなんてわからない。そういう段階でそもそも本当に作るのか？　ということをウォーターフォールでは決めないといけない。要求仕様の取りまとめに時間もコストもかかる。それにも関わらず、リリース後に統計をとってみたら結果として全く使われなかったということが起きます。過度にやらないことですね。必要なこともあると思いますが。

作った機能の60%は使われないっていうレポートもあるので、大丈夫です。498番目はまず使われません(笑)。

分散開発やリモートオフィスは上手くいくのか？

城内: 対話を重視するアジャイル開発において、各メンバーがリモートワークで参加する場合、成功するためのコツはありますか？
吉羽さん: Face to Faceで働いた経験ですね。プロジェクトの最初の1ヶ月は同じ場所で全員一緒に働くべき、というのはよく言います。チームの規律ができるまでです。それから先は分散してもいい。あとは、デイリースクラムです。Google ハングアウトでも使えばいいけど、その規律を守るための活動が必要になります。Slackなどで通知して、みんなが守らないといけません。オフィスにいれば「やるよ」って言えばいいけど、リモートではその仕組みを作らないといけない。この辺りは倉貫さんの本に詳しく書いてあります。

本を読んだらスクラムはできるのか？

城内

スクラムを始めるチームにオススメする書籍なら、どの1冊でしょうか？

吉羽さん

自分の書いた本なので「SCRUM BOOT CAMP THE BOOK」と言っておきましょうか(笑)。

「エッセンシャルスクラム」っていう結構ボリュームのある良い本が出たけれど、実際のところやってみないとわからないでしょう。本は読んだものの、教えてくれる人もいない中で、見よう見まねでやってみて上手くいくほど楽じゃない。経験者もいなくて教えてくれる人がいない状況で失敗している例はたくさんある。自分を売り込んでもしょうがないけど(笑)、経験者がいないと大変です。ウォーターフォールっぽくなってしまい価値観すら変わらない、何が正しいかすらわからなくて常に不安という状況になってしまいがちです。

城内

形だけ真似たところで、価値観が変わってなければ、自分たちの元のやり方によっていってしまうと。

吉羽さん

たとえば、スクラムにはスクラムマスター(スクラム開発におけるロールのひとつ)がいますが、外部から「今週中にこれをやってくれないと困るんだ」って言ってきた場合に、チームで相談して受け入れるかどうかを決めなければならない。今やっている作業を全部止めても良いんだったらできるかもしれないといった話を正しく伝えられるか。規律を守らなければならない、人間系もふくめて、従来のやり方に慣れている人がやるのはしんどいと思います。

誰が、スクラムマスターをやるかというのも重要で、よくある失敗は技術面で一番優秀な人がやるとか、もしくは管理者がやるというものですね。前者は技術者と兼任しようとしてチームの面倒を見きれない、一方管理者はついつい指示しちゃう。そういう(スクラムの)考え方を理解しないでやるのは大変です。

城内

始めるときはスクラムの有識者がいたほうがいいと。

吉羽さん

そうですね。最初は厚めにサポートしてもらって、あとは週1に減らしてっていうのもありです。

これは組織の成熟度、チームの成熟度にも依存するところがあります。元々自分たちで考えてやっていたという人達はそういうことしなくてもいいのかもしれないけど、SIの現場や急拡大している組織だと、チャレンジになることが多いです。

社長より給料が高くてもイイ！

嵩原

少し話題を変えて、単刀直入にお伺いしますが、どうしたら良い技術者を採用できるのでしょうか？

吉羽さん

ほとんどのエンジニアは、すごく優秀なエンジニアと働きたいと思っています。スタープレイヤーがいるのであれば、その人をもっと目立つようにするのが良いでしょう。もう一つはサラリー。それが全てでは無く、またサラリーだけ高くても仕方無いですが、バランスだと思います。「アメリカ海軍に学ぶ「最強のチームの作り方」」っていう本の受け売りですが、会社をやめる理由は、1.上司から大切に扱ってもらえないこと、2.積極的な行動を抑えこまれること、3.意見に耳を貸してもらえないこと、4.責任範囲を拡大してもらえないこと、などの理由があって、給料の問題は5番目です。給料が高いからって、責任範囲が小さければつまらないし、面白いっていうのはみんながエンジニアとして優秀だったりこの人すげーっていう人がいたり、コマンドコントロールされないで自分たちで考えてどんどんできる環境だったりすることが重要。

極論すると、スタープレイヤーは社長より給料をもらっていたって良いと思います。ただし、スターになれる環境なのか？　出てくる杭が打たれないで伸びまくれるかが重要ですね。

城内

それは、スタープレイヤーは社内外への発信が必要ということでしょうか？

吉羽さん

もちろん。クラスメソッドはブログをすごい書いているけれど、誰が有名なんだろうっていうとなんとなくわからないところがある。横田さんは有名で露出もしているけど、他にこの人がもっと目立ったほうが良いっていう人がいるのなら、戦略的なところもでてくるけど、明らかなスターをどうやって作るのかというのを考えてもいいと思う。

みんながブログ書きすぎていて誰が一番書いているかわからないところがあるし(笑)。

エンジニアの評価と組織のカルチャー

嵩原

スタープレイヤーはどう評価するべきでしょうか？

吉羽さん

評価の仕方は会社によってまちまちで難しいのですが、働いている年数が長いかは関係なく、そのメンバーの成果によって会社にインパクトが出ているか。数字での評価は大事です。でも定量評価に偏ると、他人の手柄を横取りしてでも評価を良くしたいって人がでてくるので、セットで定性的な評価も必要です。

カルチャーに従っているかなどは定性的要素ですね。それと360度評価もやったほうが良い。

評価は1年に1回やれば良いのかいうと、それはアジャイルではないですよね。検査と適応が大切です。1 on 1で、上司と部下が2週間に1回話すとか、目標の到達具合は3ヶ月に1回確認するとか、もしくは意味の無くなってしまった目標を変えるなど、継続的にやった方が良いのは間違いないです。

定量と定性、目標はムービング・ターゲットであること、フィードバックサイクルを回すということです。トップが主観で「こいつ頑張ったから評価を上げる」という次元の話ではないです。クラスメソッドも100人を超えたということなので、誰が評価をしているかは知らないですけど、もし最終的に評価をする人に権限が集中しているようなら段々見きれなくなってくる。そこら辺で、評価システムっていうのを一回考えなければいけなくなる。人数の桁が変わると組織構造はすべからく変わっていくし、数十人の組織が100人を超えると場合によってはカルチャーも変わってしまうかもしれない。その時に何が起こるかっていうと、人がいっぱい辞めていく。昔はもっと良かったのに最近はイケイケ感がなくなってテンションが下がってきたとか。カルチャーの維持は優先だし、評価の基準の中にカルチャーを体現しているかっていうのはあった方が良い。だから定量評価だけに寄せるとおかしなことになります。

アジャイル・クラウド・DevOps の前に必要な、本当に大切なこと

嵩原

今日はいろいろとお話を伺わせていただきました。ありがとうございます。

アジャイルにせよクラウドにせよ DevOps にせよ、世の中には正解と思われる手法や技術がたくさんあります。それらを実践していくために本当に必要なことって何でしょうか？

吉羽さん

変化への恐怖を克服するってことが全員に必要じゃないでしょうか。ビジネスも変わるし、やり方も変わるし、技術も変わる。絶対変わるんですよ、本人が望もうが望むまいが。そうすると、その変化に対応しなければいけない。それを覚悟できるかどうか…。

もし、今大きい会社に勤めていて定年まであと10年だという状況なら、余計なことしなければ逃げきれると年齢が上がれば思うかもしれないけど、そもそも今の現役の世代って会社が10年後も存続しているかまったくわからない。ましてや、僕らの世代は年金がいつ貰えるかもわからない。そうすると自分の責任で変化に対応して食っていかなければいけない。変化に適応する必要があると思えば、技術を身に付けようってなる。

変化はみんな怖いです。でも、変化をしないとマズイんだっていう認識が一番必要なんじゃないですかね。コンサルを呼ぶっていう次元の話じゃなくて、組織として、人として、生き方として、変化をしちゃう、それを認めて対応することだと思います。

怖いですよ。僕だって怖いし。このビジネス食えるかなって(笑)。